Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They typically consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. IP packets are routed to the destination by routers in a connection-less manner. Therefore, packets comprise IP header and payload information, and the header comprises, amongst other things, a source and destination IP address.
For scalability reasons, an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal. With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
LTE—Long Term Evolution
UMTS (Universal Mobile Telecommunications System) is the 3G (3rd Generation) mobile communication system standardized by 3GPP (3rd Generation Partnership Project).
The 3GPP (3rd Generation Partnership Project) launched a study item “Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”. The study will investigate means of achieving major leaps in performance in order to improve service provisioning, and to reduce user and operator costs. Out of that and because interworking with other radio access technologies should be possible, the need arose for a new evolved Packet Core Network.
An exemplary representation of the E-UTRAN architecture is given in FIG. 1. The E-UTRAN consists of evolved Node Bs (eNB or eNodeB), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node (also referred to in the following as UEs, MS or MNs).
The eNB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. Further, it performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL-QoS (Quality of Service), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers. The eNBs are connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) via the S1-MME, and to the Serving Gateway (S-GW) by means of the S1-U interface.
The S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and Packet Data Network Gateway). For idle state UEs, the S-GW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the S-GW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN (Serving GPRS Support Node). The MME also terminates the S6a interface towards the home HSS for roaming UEs.
The Packet Data Network Gateway (PDN-GW) provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PDN-GW for accessing multiple PDNs. The PDN-GW performs MN IP address allocation, policy enforcement, packet filtering (e.g. deep packet inspection, packet screening) for each user in order to map the MN's traffic to an appropriate QoS level, charging support, lawful interception and packet screening. The PGW performs the function management of a HA in case of MIPv6 and of LMA in case PMIPv6 protocols are used for mobility. Another key role of the PDN-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies.
To summarize the above, in order to support the new E-UTRAN access, the new 3GPP Core Network is mainly separated into three logical entities. At first, in the user plane the PDN-GW is the gateway to the external networks and the global mobility anchor for mobility between 3GPP and non-3GPP access technologies (like CDMA2000, WiMAX or WIFI). Second, another user plane entity, the Serving Gateway, is the mobility anchor for mobility between 3GPP accesses (E-UTRAN, UTRAN, GERAN). Third, a Mobility Management Entity is the control plane entity responsible for the mobility management of mobile terminals moving between different EUTRAN base stations (eNodeBs) and also responsible for the session management.
As described above, the MME is responsible for mobility management and session management. For each mobile terminal attached to an MME, specific mobility management and evolved packet system context information is stored in the MME. These contexts comprise, e.g. the mobility state, the temporary identity, the current Tracking Area List, last known cell, authentication vectors, access restrictions, subscribed QoS profile, subscribed charging characteristics, and for each active PDN connection the APN (Access Point Name) in use, IPv4/IPv6 addresses, PDN-GW address for control plane, and also information for each EPS (Evolved Packet System) bearer within the PDN connection, as for example EPS bearer QoS profile, EPS bearer charging characteristics.
Public Land Mobile Networks & Roaming Agreements
A public land mobile network (PLMN) is a network that is established and operated by an administration or by a recognized operating agency for providing land mobile telecommunications services. PLMNs interconnect with other PLMNs and Public switched telephone networks (PSTN) for telephone communications or with internet service providers for data and internet access. A PLMN may be considered as an extension of a fixed network, e.g. the Public Switched Telephone Network (PSTN) or as an integral part of the PSTN. This is just one view-point on PLMN. PLMN mostly refers to the whole system of hardware and software which enables wireless communication, irrespective of the service area or service provider. A separate PLMN may be defined for each country or for each service provider.
Every PLMN organisation has its own management infrastructure, which performs different functions depending on the role played and the equipment used by that entity. However, the core management architecture of the PLMN organisation is similar, such as: providing services to its customers; infrastructure to fulfil the services (advertise, ordering, creation, provisioning, . . . ); assuring the services (Operation, Quality of Service, Trouble Reporting & Fixing . . . ); billing the services (Rating, Discounting, . . . ).
Not every PLMN organisation will implement the complete Management Architecture and related processes. Some processes may be missing depending on the role a particular organisation is embodying. Processes not implemented by a particular organisation are accessed via interconnections to other organisations, which have implemented these processes. The Management architecture itself does not distinguish between external and internal interfaces.
A MN subscribed to 3GPP services has a home PLMN (HPLMN) that maintains the subscription data, allowed services and QoS levels. When the MN is attached to a network different from the HPLMN, the MN is indicated as roaming node and the visited network is denoted as visited PLMN (VPLMN).
In general, “roaming” can be defined as the ability for a cellular customer to automatically make and receive voice calls, send and receive data, or access other services, including home data services, when travelling outside the geographical coverage area of the home network, by means of using a visited network.
The differentiation between HPLMN and VPLMN is technically given by the type of subscriber entry in a specific network. When a mobile device enters a new visited network and has no entry in the home subscriber register of the network (e.g. Home Location Register, HLR, in GSM networks or local customer database in WLANs), the required subscriber data must first be requested by the visited network e.g. from the subscriber's home network in order that the subscriber can be authenticated and any authorization for using the network services can be checked. The “visiting” subscriber acquires an entry in a user database of the visited network (e.g. Visited Location Register, VLR) and the authorized network services are enabled. If there is no roaming agreement between the two networks, i.e. HPLMN and VPLMN, maintenance of service is impossible, and service is denied by the visited network.
A roaming user is connected to the E-UTRAN, MME and S-GW of the visited network. However, by using the home network's PDN-GW, the user has access to the home operator's services even while in the visited network.
Generic Access Network (GAN)
Another system specified by 3GPP and independent from LTE/SAE is the Generic Access Network (GAN) also known as Unlicensed Mobile Access (UMA). GAN provides access to mobile operator services and to the 3GPP core network using a generic IP connection (e.g. WLAN+DSL). With GAN certain 3GPP protocols are tunnelled from the terminal over the IP connection to the 3GPP Core Network (see FIG. 2). Furthermore, GAN supports seamless handover between wireless LANs and the 3GPP access for dual-mode terminals. On the cellular network, the mobile terminal communicates over the air with a NodeB, through a base station controller, to nodes in the core network. Under the GAN system, when the terminal detects a wireless LAN, it establishes a secure IP connection through a gateway to a server called a GAN Controller (GANC) on the 3GPP network. The GANC presents itself to the mobile core network as a standard cellular base station. The terminal communicates with the GANC over the secure connection using existing GSM/UMTS protocols. Thus, when the terminal moves from a 3GPP to an 802.11 network, it appears to the core network as if it is simply on a different base station.
In the following, some of the standard GAN procedures will be described with reference to FIG. 5-9. Some of the embodiments of the invention partly reuse messages of the GAN protocol to perform an improved handover.
Discovery Procedure
When a MS supporting GAN first attempts to connect to a GAN, the MS needs to identify the Default GANC. Each GAN capable MS can be configured with the FQDN (or IP address) of the Provisioning GANG. The MS first connects to a GANC in the HPLMN of the MS, by establishing a secure IPsec tunnel and a TCP connection using the provisioned or derived addresses. The MS obtains the FQDN or IP address of the Default GANC in the HPLMN through the Discovery procedure. The following steps of the discovery procedure are illustrated in FIG. 5.                1. If the MS has a provisioned or derived FQDN of the Provisioning GANC, it performs a DNS (Domain Name Service) query to resolve the FQDN to an IP address.        2. The DNS Server returns a response including the IP Address of the Provisioning GANC.        3. The MS establishes a secure tunnel to the Provisioning GANC.        4. The MS sets up a TCP connection to a well-defined port on the Provisioning GANC. It then queries the Provisioning GANG for the Default GANC, using GA-RC DISCOVERY REQUEST. The message contains:                    Cell Info: Either current camping GERAN/UTRAN cell ID, or last LAI where the MS successfully registered, along with an indicator stating which one it is.            Generic IP access network attachment point information: AP-ID            MS Identity: IMSI.                        5. The Provisioning GANG returns the GA-RC DISCOVERY ACCEPT message, using the information provided by the MS (e.g. the CGI, Cell Global Identifier), to provide the FQDN or IP address of the Default GANC. This is done so the MS is directed to a “local” Default GANC in the HPLMN to optimize network performance.        6. If the Provisioning GANC cannot accept the GA-RC DISCOVERY REQUEST message, it returns a GA-RC DISCOVERY REJECT message indicating the reject cause.        7. The secure IPsec tunnel to the Provisioning GANC is released. It shall also be possible to reuse the same IPsec tunnel for GAN Registration procedures. In this case the IPsec tunnel is not released.Registration Procedure        
Following the Discovery procedure the MS establishes a secure tunnel with the secure gateway of the Default GANC, provided by the Provisioning GANG in the Discovery procedure, and attempts to register with the Default GANG. The Default GANG may become the Serving GANG for that connection by accepting the registration, or the Default GANG may redirect a MS performing registration to a different Serving GANG.
GANC redirection may be based on information provided by the MS during the Registration procedure, operator chosen policy or network load balancing. The following steps for the registration procedure are illustrated in FIG. 6.                1. If the MS was provided the FQDN of the Default or Serving GANG, the MS shall perform a DNS query to resolve the FQDN to an IP address.        2. The DNS Server returns a response.        3. The MS shall then set up a secure IPsec tunnel to the GANG. This step may be omitted if an IPsec tunnel is being reused from an earlier Discovery or Registration.        4. The MS then sets up a TCP connection to a TCP port on the GANG. The TCP port can either be a well-known port or one that has been earlier received from the network during Discovery or Registration. The MS shall attempt to register on the GANG by transmitting the GA-RC REGISTER REQUEST. The message includes:                    Cell Info: Either current camping GERAN/UTRAN cell ID, or last LAI where the MS successfully registered, along with an indicator stating which one it is. In addition, the MS includes the UARFCN of the current serving cell (if that cell is a UTRAN cell). Generic IP access network attachment point information: AP-ID.            MS Identity: IMSI.                        5. If the GANG accepts the registration attempt it shall respond with a GA-RC REGISTER ACCEPT. The message contains:                    GAN specific system information (e.g.):            GAN Mode Indicator: GAN A/Gb mode or GAN Iu mode.            Cell description of the GAN cell:                            a. If GAN Iu mode selected: The UTRA ARFCN (UARFCN) and Primary Scrambling Code (PSC) corresponding to the GAN cell.                                    Location-area identification comprising the mobile country code, mobile network code, and location area code corresponding to the GANC cell.            Cell identity identifying the cell within the location area corresponding to the GAN cell.                        In this case the TCP connection and the secure IPsec tunnel are not released and are maintained as long as the MS is registered to this GANC.        6. Alternatively, the GANC may reject the request. In this case, it shall respond with a GA-RC REGISTER REJECT indicating the reject cause. The TCP connection and the secure IPsec tunnel are released        7. Alternatively, if the GANC wishes to redirect the MS to (another) Serving GANC, it shall respond with a GA-RC REGISTER REDIRECT providing the FQDN or IP address of the target Serving GANC. In this case the TCP connection is released and the secure IPsec tunnel is optionally released depending on if the network indicates that the same IPsec tunnel can be reused for the next registration.PS (packet switched) Handover from UTRAN to GAN (Preparation Phase) FIG. 7a         1. Based on measurement results and knowledge of the RAN topology, the source SRNC decides to initiate a combined hard handover and SRNS relocation.        2. The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC To Target RNC Transparent Container) to the SGSN.        3. The SGSN determines the target cell is the GANC, based on the contents of Relocation Required. It then sends the Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source RNC To Target RNC Transparent Container, RAB To Be Setup) to the GANG.        4. One or more GAN PTCs are established between the GANG and MS. Upon the GA-RRC PTC establishment, the PS domain GA-RRC sublayer entity in the MS enters the PTC-ACTIVE substate.        5. The GANG sends the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent Container, RABs Setup, RABs Failed To Setup) to the SGSN.PS Handover from UTRAN to GAN (Execution Phase) FIG. 7b         1. Upon receiving the positive acknowledgement from the GANG to serve the MS, the SGSN initiates the Execution Phase by sending the Relocation Command to the source SRNC.        2. a) The RNC may start forwarding GTP PDUs to the GANG while still transmitting them in the downlink to the MS. This forwarding is routed via the Iu-PS interface. The GANG may buffer, start a blind transmission of downlink user data towards the MS over the allocated PTC(s), or discard these forwarded GTP PDUs, depending on the QoS profile, network conditions, and whether it supports data forwarding.                    b) The RNC instructs the MS to initiate the switch to GAN via the Physical Channel Reconfiguration message.            c) The RNC sends the Forward SRNS Context message to the GANG via the SGSN.                        3. Immediately after receiving the Physical Channel Reconfiguration message, the MS sends GA-RRC RELOCATION COMPLETE message to the GANG. Upon receiving this message and the Forward SRNS Context message, the GANG becomes the Serving RNC.        4. Immediately upon receiving the GA-RRC HANDOVER COMPLETE message from the MS, the GANG sends the Relocation Detect message to the SGSN.        5. The GANG sends the Relocation Complete message to the SGSN.        6. The MS, GANC and CN exchange user data via the established PTC.        7. The SGSN releases the Iu-PS connection with the old RNC.        8. If the Routing Area of the GANC cell (as indicated by the GANC to the MS in GAN registration) is different from that under the old RNC, then the MS performs the Routing Area Update procedure.PS Handover from GAN to UTRAN (Preparation Phase) FIG. 8a         1. The MS is in active packet flow exchange with active PDP Context(s) and PTC(s) in the GAN.        2. The GANC may send a GA-RRC UPLINK QUALITY INDICATION if there is a problem with the uplink quality for the ongoing session. Uplink Quality Indication is information sent by the GANC to the MS indicating the crossing of an uplink quality threshold in the uplink direction. Whenever the MS receives an indication of bad quality, it should start the relocation procedure, as described in the next step. Alternatively, MS can use its local measurements to decide to initiate the handover procedure.        3. The MS decides to initiate a PS handover from GAN to UTRAN by sending GA-RRC RELOCATION INFORMATION message to the GANC. The GA-RRC RELOCATION INFORMATION message indicates a list of target cells, identified by cell ID, in order of preference for PS handover, and includes the received signal strength for each identified cell.        4. The GANC selects a target RNC based on the contents of the GA-RRC RELOCATION INFORMATION message. It sends a Relocation Required message to the SGSN containing the selected RNC information.        5. The SGSN sends a Relocation Request message to the target RNC.        6. The RNC performs the necessary allocation of radio and Iu transport resources.        7. The RNC returns a Relocation Request Acknowledge message to the SGSN. This message contains a transparent container that contains channelization information needed by MS to access UTRAN.PS Handover from GAN to UTRAN (Execution Phase) FIG. 8b         1. The SGSN begins the Execution Phase by issuing the Relocation Command message to the GANC. The message contains the channel access information in the target UTRAN cell.        2. a) The GANC sends the GA-RRC RELOCATION COMMAND to the MS. This message contains the information from the Relocation Command received in Step 1 earlier.                    b) The GANC also sends the Forward SRNS Context message to the target RNC via the SGSN.                        3. The SGSN relays the Forward SRNS Context message to the target RNC.        4. Upon receiving the GA-RRC RELOCATION COMMAND, the MS immediately suspends uplink GTP PDU transfer. It immediately begins accessing the UTRAN using the indicated channelization parameters in the message. The MS's access attempt is detected by the Node B and RNC, and is reported to the SGSN via the Relocation Detect message.        5. The MS completes the lower layer setup and configuration, and sends the RRC Physical Channel Reconfiguration Complete to the target RNC. This triggers the target RNC to send the Relocation Complete message to SGSN. At this stage, the target RNC assumes the role of SRNC for the MS.        6. The packet data flow is now active via the UTRAN.        7. The SGSN releases the Iu-PS connection by sending the Iu Release Command message to the GANC, to which GANG responds with Iu Release Complete message.        8. If the Routing Area of the UTRAN cell is different from that of the GAN cell, then the MS performs the Routing Area Update procedure.PTC Activation when Gang Receives Relocation Request        
The following FIG. 9 depicts the Packet Transport Channel activation procedure when the GANG receives the Relocation Request message from the SGSN.                1. The MS has successfully registered with the GANG. The MS, GANG and SGSN perform signalling procedures related to PS handover.        2. The SGSN sends the Relocation Request message to the GANG and includes the RAB ID, the CN Transport Layer Address (IP address) and the CN Iu Transport Association (GTP-U Tunnel Endpoint Identifier, TEID) for user data.        3. The GANG sends the GA-RRC RELOCATION REQUEST message to the MS to request activation of the Packet Transport Channel(s) for PS handover purposes. The message includes the RAB ID, a TEID that the GANG assigns to the MS for downlink data transfer, the GANG PTC IP Address (i.e., the destination address for PTC GA-RRC PDU messages from the MS) and the GANG TEID assigned by the GANG for uplink data transfer, for each of the RABs.        3. The MS acknowledges the activation of the PTC(s) in the GA-RRC RELOCATION REQUEST ACK message. The PS domain GA-RRC sublayer entity in the MS transitions to the GA-RRC-CONNECTED state and the PTC-ACTIVE substate for each PTC and starts the PTC Timer for each PTC.        4. The GANG sends the Relocation Request Ack message to the SGSN to complete the handover preparation procedure. The GANG includes the RAB ID, the RAN Transport Layer Address (i.e., the GANC's Iu-PS IP address) and the RAN Iu Transport Association (i.e., the TEID that the GANG assigned to the MS) for each RAB.        5. PS handover is performed.        6. The MS transfers uplink user data by sending a GA-RRC PDU message to the GANG PTC IP address received in step 3. The message includes the GANG TEID received in step 3, which allows the GANG to relay the GA-RRC PDU message payload using the correct GTP-U tunnel on the Iu-PS interface. The GANG relays the message payload to the SGSN in the Iu-PS G-PDU message.        7. The SGSN transfers downlink user data by sending a Iu-PS G-PDU message to the GANG Iu-PS IP address received in step 5. The message includes the MS TEID received in step 5, which allows the GANG to relay the Iu-PS G-PDU message payload using the correct PTC on the Up interface. The GANG relays the message payload to the MS in the GA-RRC PDU message.        
The specific scenario explained in the following applies to the above described 3GPP system environment. The starting point of the scenario is that a roaming UE, i.e. the UE is connected to a cell of a base station (eNB) of a visited network operator (e.g. VPLMN1), is moving out of coverage of VPLMN1's cells. One exemplary use case for this scenario is that the VPLMN1 cell is a macro cell and the user is entering a subway station or underground shopping mall and the power of the signal of the VPLMN1 cells is too low to reach the UE in the underground. Furthermore, there is no other base station of VPLMN1 deployed in the underground, however, cells of other operators (e.g. VPLMN2) are in the coverage of the UE in the underground, for example because the VPLMN2 operator has deployed eNBs covering smaller cells in the underground.
In order to support seamless mobility in the scenario described above, it should be possible for an active UE to handover from cells of VPLMN1 to cells of VPLMN2 (see FIGS. 3 and 4).
The capability of performing seamless handover may depend on the relationship between the different operators of the VPLMNs. For example, if there is a special kind of mutual roaming relationship/agreement between all the involved operators, i.e. the home operator of the UE (HPLMN), the visited operator VPLMN1 and the visited operator VPLMN2, the networks may be configured to support active handover, i.e. the source access eNBs are aware of the target access eNBs, and context transfer and data forwarding between the two visited PLMNs is possible. However, if there is a roaming agreement between the home operator of the UE (HPLMN) and VPLMN1 and also an agreement between HPLMN and VPLMN2, but no specific roaming agreement between VPLMN1 and VPLMN2, an active handover with context transfer etc. is not possible.
Even if the UE is able to measure the VPLMN2 cell and report information to the source eNB to which the UE is still connected, the source eNB is not aware of the target eNB, i.e. does not know the target eNB to which the UE shall perform the handover. And even if the source eNB would be aware of the Enhanced Global Cell Identity (ECGI) of the target cell and would request handover, the source MME in the VPLMN1 network may not find the target MME or is not allowed to trigger active handover to the target network, and thus, the UE will not be triggered to do handover. In addition, the UE will not be informed about an unsuccessful handover attempt to VPLMN2.
Thus, if there is no special roaming agreement between VPLMN1 and VPLMN2, after loosing coverage, the UE has to search for a new cell in VPLMN2 and do an attach, thereby disrupting the service.
In the following two possibilities are presented to perform a handover between two VPLMNs that do not have a roaming agreement for allowing an active/seamless handover of a MN.
One possible solution is that the UE, prior to loosing coverage completely, goes to IDLE mode and starts to scan cells of other PLMNs in the vicinity. Then, when a cell of another VPLMN is found, the UE can connect to the new cell and perform a Tracking Area Update (TAU) with the “active flag” set. Because of the active flag, the MME triggers activation of all radio and S1 bearers, thus the user plane is setup and the session continuity is guaranteed.
However, this mechanism would still require at least some kind of roaming relationship between VPLMN1 and VPLMN2, because during the TAU procedure the new MME contacts the old MME to retrieve context information for the UE. Further, the handover performance is not optimal in this case. Downlink data sent from the HPLMN to the old VPLMN can get lost, and delivery is delayed during the scanning phase of the VPLMN2 cells and during the handover execution, because bearers in the target access are setup in a re-active manner.
A first sub-issue of the IDLE mode solution above is when the UE starts with the handover procedure. As already mentioned, there is no special roaming agreement between VPLMN1 and VPLMN2, and therefore, VPLMN1 eNBs are not aware of VPLMN2 eNBs. Even if the UE reports VPLMN2 cells to the VPLMN1 eNB, the VPLMN1 eNB is not able to trigger the handover.
One possibility to overcome this issue is that the UE measures and compares the signal strength of the eNB in VPLMN1 and of the eNB in VPLMN2. If the source eNB signal strength is below a threshold and the target eNB signal strength is above a threshold, the UE does not wait for the Handover Command from the source eNB any longer, but starts with the handover to the new eNB in VPLMN2.
This UE behaviour may cause a UE-initiated handover although network-initiated is also possible. The problem is that the UE does not know that there is no special roaming relationship between the two PLMNs and that the source eNB can not trigger the handover. Thus, one way to avoid that the UE falsely initiates the handover is that in case the source MME can not send a handover (forward relocation) request to the target MME, the UE is informed by the source MME/eNB that network-initiated handover is not possible. Only then, the UE starts with handover attach to the new eNB in VPLMN2.
As already mentioned, the second sub-issue of the IDLE mode solution explained above is that even this solution requires some kind of roaming relationship between VPLMN1 and VPLMN2. This can be avoided by the UE indicating the HPLMN as source network during the TAU procedure. Then, the target MME will ask the HPLMN about the context, and the HPLMN can retrieve the context from the source MME. Another problem is that there is still a handover delay, because the UE is already attached to the target eNB before context is retrieved from the source access.